Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000009_owner-urn-ietf _Tue Oct 8 08:36:59 1996.msg

Internet Message Format | 1997-02-19 | 8KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA01576 for urn-ietf-out; Tue, 8 Oct 1996 08:36:59 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA01571 for <[e-mail]>; Tue, 8 Oct 1996 08:36:56 -0400
Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA14095  (mail destined for [e-mail]); Tue, 8 Oct 96 08:36:53 -0400
Received: from [192.71.220.107] (zap.swip.net [192.71.220.107])
        by nic.cafax.se (8.8.Beta.2/8.8.Beta.2) with ESMTP
        id OAA23610;
        Tue, 8 Oct 1996 14:35:09 +0200 (MET DST)
X-Sender: [e-mail]
Message-Id: <v0300780cae7ff33cf01b@[192.71.220.107]>
In-Reply-To: <96Oct8.005924pdt."2768"@golden.parc.xerox.com>
References: <[e-mail]>
 (message    from Patrik Faltstrom on Mon, 7 Oct 1996 21:30:40 PDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 8 Oct 1996 14:33:55 +0200
To: Larry Masinter <[e-mail]>
From: Patrik Faltstrom <[e-mail]>
Subject: Re: [URN] advantages of NAPTR over PURLs
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
Reply-To: Patrik Faltstrom <[e-mail]>
Errors-To: [e-mail]

At 00.59 -0700 96-10-08, Larry Masinter wrote:
>> The A record does not have a priority. MX-records do have that,
>> A records does not. You can not change the spec of A-records.
>
>Tell me again why replicated services need to have 'a priority'.
>What requirements does it help satisfy?

Because the cost, performance or other issues. When using A-records
the servers _have_ to be the same. When talking about URNs I personally
would like to be able to host these kind of requirements, even though
(or especially because of the fact that) we don't know everything about
all future protocols or resolution services.

>Are you saying that you'd expect NIS to work with NAPTR but not to
>work with long A records?

No, I don't expect to use NAPTR to be used in NIS. This was an example
of a broken resolver system which have to be replaced. Because it has
to be replaced anyway, it shows that the requirement of choosing PURLs
because you can use existing resolver implementations is not always
true. If you have to change the resolver anyway because of bugs, you can
change to something that supports SRV and NAPTR.

>PURLs
>handle renaming of resources by letting you go to the PURL server and
>tell the PURL server where the resource is now.
>    PURL -> URL -> resource
>If the resource gets renamed, you change the PURL -> URL mapping. No
>second level abstraction needed.

It is needed if the service moves from one resolution protocol (HTTP)
to something else because the resolution protocol is part of the PURL,
which is not the fact with the NAPTR proposal.

>This protocol uses DNS, but it is still a protocol. It has a syntax,
>the syntax must be parsed, the syntax has no version information, the
>syntax is not in itself widely implemented, might need to be changed,
>etc.
>
>The PURL system also has a single protocol for finding an appropriate
>resolution service. That protocol consists of doing a DNS A record
>lookup on duns.resolver.purl.org, then picking one of the IP addresses
>you get, and doing a HTTP request.

You need both DNS and HTTP. Not only DNS. I trust the lifespan for DNS
more than the lifespan for HTTP (i.e. not that HTTP will go away but
might be replace with something else like LIFN resolvers).

>While HTTP might not be 'long-lived', are you claiming that this
>design of NAPTR is longer-lived, or should be? How long? On what
>grounds to you evaluate longevity of protocols? There is "N2L", "N2C"
>and "N2R", will there not be another kind of category of "N2X" for 20
>years?

The only thing I claim is that the NAPTR proposal follows the URN
requirements RFC better than the PURLs. Of course some of this is
depending on what "trust" each one of us personally have for each
one of the protocols that are used.

I have just stated my personal opinion.

>I'm just asking you to write down what the advantage actually is.
>I understand and I'm willing to trust that there advantages, but you
>should say.

Let's say that I have a Whois++ server with all metadata of all
documents we have on our www-server. That server is replicated into
a LDAPv3 server so it also can be accessed via LDAPv3, and not only
Whois++. Because of schema-definition problems, the Whois++ server
is the primary server, so the Whois++ server should have higher
priority than the LDAPv3 one (or vice versa).

I.e. when mirroring data between servers -- especially when mirroring
between servers with different access protocols which I think will be
more and more common -- loss of data will happen. You also might loose
data if you have a primary server and a secondary one outside a
firewall etc. Just as with MX records, you should first try to access
the internal server, and then the external one.

>To reiterate a bit on the 'protocol' issue: it's always possible to
>delegate to some other protocol in a 303 Location: response; at least,
>though, if you force people to register "dunslink" and "rcds" as new
>URL schemes, we'll have a mechanism for dealing with those tokens in a
>standards-track way.

This is true, but you do need then:

 DNS -> HTTP -> new_protocol

Instead of

 DNS -> new_protocol

>As you've specified it, there's no change-control
>on what those tokens might mean: if there are two versions of
>rcds, should NAPTR records upgrade all their records when the resolver
>upgrades from rcds1 to rcds2? If there's a version skew between the
>client rcds and the server rcds such that the server rcds can't
>respond to the client's ancient rcds implementation, should the
>rejection influence the handling of priorities?

This should be something the one designing (choosing) the protocol
used in the NAPTR records. If the rcds protocol is not backward
compatible in future versions, that is obviously a bad choice for
the use as resolution protocol.

This is not something that should be part of the NAPTR framework.
What the URN framework is, is a way of describing what the NAPTR
framework have to handle, which in turn sets limitations and
recommendations on the resolution protocols used. When using PURL,
you have to use HTTP, which already today is changed.

With NAPTR (and rcds for example) you have something that can use
UDP for the whole resolution process which is more effective than
using TCP and HTTP.

>     z3950r://isite.bogus.com/0123@ab125212312xx0A
>and you refer to it with
>     urn:duns:002372413:annual-report-1997
>
>you can still use PURLs to do it, by looking up
>    http://duns.resolver.purl.org/002372413:annual-report-1997
>
>and getting back a
>    303
>    Location: z3950r://isite.bogus.com/0123@ab125212312xx0A

Yes, _if_ you have both DNS and HTTP protocols part from
the Z39.50 protocol.

>Maybe one way to improve PURLs would be to have the 'redirect' message
>in HTTP allow pattern-redirects.

This is from my point of view something that might be needed anyway,
but is an implementation problem and not a HTTP problem.

Note that I am not saying that PURLs should go away, die or something
like that. It works perfectly in some environments and solve tons
of problem todays version of usage of URLs have. You have though to
use HTTP and you have no priority (as two things missing). With
NAPTR and SRV records, you can change the protocols aswell without
using HTTP, i.e. with only the use of DNS, and that is for me
something that is very important. DNS have been around some
7 years longer than HTTP.

   Regards, Patrik